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NEWSLETTER SUBMISSIONS 


Submissions are accepted at all times and are normally used in the next 
issue to go to press regardless of date of receipt. 


Material submitted in machine readable form is particularly desirable 
because it can be edited and incorporated into the newsletter format more 
easily. Higher quality reproduction is also possible this way. Contact Bob 
Hassinger for further details on acceptable media and formats if you plan to 
make a submission in machine readable form. 


FUTURE DEADLINES 


I have been given the following deadlines for the next issue: May 1. This 
is the date my material must be in the hands of the person I send it to. In 
order to make it into that issue, your material must reach me ten days before 
that date to cover mailing delays and to give me time to edit and retype it. 
Machine readable input is greatly appreciated, particularly near deadline time. 
In some cases it may be possible to send your material directly to my systems 
electronically. If you are interested in this, give me a call. 


{2 BIT COMMITTEE 


Robert Hassinger 
- address above - 


(617) 435-3452 


COS/DIBOL and WPS liason 
Lawrence H. Hisenberg 
17141 Nance Street 
Encino, California 91316 
(213) 788-0354 


Education, Multiuser systems, PASCAL 61 
Father Geoffrey Chase 0.S.B. 
Portsmouth Abbey School 
Portsmouth, RI 02871 
(401) 683-2000 


Representitive to DECUS Product Planning Committee 
Jim van Zee 
Lab Data Systems 
10320 Ravenna Ave NE 
Seattle, Washington 98125 
(206) 522-6950 


COMMERCIAL SOFTWARE 


I frequently get calls and letters from people looking for software for 
commercial applications. They would like to find something in the DECUS Program 
Library but I have to tell them that very little along this line has been 
submitted. I think generally, commercial applications seem to written by people 
interested in making money. The DECUS Library seems to get other types of 
software, more from people who are interested in sharing what they have done 
with other users rather than making money with it. I find these people are 
frequently in research and education rather than in the commercial sector and 
the software they contribute reflects this. As a result I have a hard time 
helping these people in the context of the DECUS Library. 


Just recently David B. Kanter sent me some new material on a package that 
has been available commercially since 1978 that might help some of these people. 
It is called GIANT/8 and it is available at prices that are more realistic than 
many others, more in line with what is going on in the microcomputer world. The 
package runs under the COS-310 operating system which you need to use it. It is 
available in one form or another for a wide range of 12 bit systems up through 
the DECmate II. 


I have never had a chance to work with GIANT/8 but I know it has been used 
quite a bit in the DECUS office for administrative functions so it might be 
worth looking into. David is president of Solutions Unlimited, P.O. Box 12053, 
Overland Park, KS 66212, (913)236-9449. 


TKPLOT UPDATE IN DECUS PROGRAM LIBRARY 


The DECUS Program Library has announced the availability of Version 2/3 
(July 1983) of Eugene J.M. Lynch's TKPLOT (DECUS 8-888). TKPLOT is used with 
Tektronix 4010 terminals in O0S/8 FORTRAN IV programs. It also requires the 
FORTRAN IV Plotter Routines. Version B works with a 4010 connected as the 
Console Terminal and Version C works with a 4010 connected on an auxiliary KL8 
type interface. The following is the catalog abstract: 


"The programming system presented here enables a Tektronix 4010 series 
Graphic Terminal, or a terminal which emulates it, to be used as the plotting 
device with a PDP8/12 family computer executing an OS/8 FORTRAN IV program which 
uses the Plotting Subroutines. The Graphic Input capability of the terminal is 
used to return the coordinates of designated display points to the program, and 
to enable interactive annotation of a screen display from the terminal keyboard. 


If a Tektronix Hard Copy Unit is attached to the terminal it may be used under 
program control. 


"A file may be designated to receive all of the information necessary to 
reproduce screen displays on other graphic devices. Displays are saved 
selectively in this file, from which they may be reproduced on an incremental pam 
plotter or other graphic device on the host computer, or transmitted for . 
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reproduction elsewhere. 


"Version B corrects minor errors in Version A, adds the Graphic Input 
routine and a convenience routine for emulator users, amends subroutine entries 
so that illegal calls are handled in a kindly manner and requires a bit less 
memory. 


"Version C has all of the features of Version B and allows the console 
terminal to be used both as the plotting and as the alphanumeric FORTRAN 
terminal output device. This version may also be used in a FORTRAN program 
running under OS/8 in the RTS-8 background. 


"Note: Changes and Improvements: Version B: Use of Console as graphics 
device. Use with RTS-8 both versions: Addition of ASCII character 
transmission and Graphics Input Routines error correction.” 


The documentation is only available in hardcopy form (i.e. not on the program 
media). Media (service charge codes): Manual-(EC), DECtape-(HA), Floppy 
Diskette-(KA). 


DECMATE II SOFTWARE 


I wrote an article for the last issue of the Newsletter that was quite 
critical of the CP/M and MBASIC options for the DECmate II. Since I still have 
not seen that Newsletter, I am not sure if the article actually got printed. 
The way things have been going you never know. In any case, the point was that 
under the CP/M option in MBASIC you could not access the serial I/0 ports to 
interface, in my case, to a digitizing tablet. I was helping a small research 
lab that had been trying to use the tablet over noisy dial up lines to a very 
primitive Perkin Elmer system without success. They had recently gotten a 
DECmate II for word processing that they absolutely love. In fact they like it 
so much that the principle investigators have bought there own DECmate IIs for 
use at home and the lab is trying to scrape up the money for another one. 


The idea was that the DECmate is really a computer and the data acquisition 
task with the tablet is really very easy so why not use the in house DECmate and 
avoid the phone and PE problems. The tablet communicates via normal ASCII ona 
standard RS232 line that should work fine on the serial ports of the DECmate II, 
and a language like BASIC should allow you to do the small amount of programming 
required by the task. Unfortunately, as I said, MBASIC seems unable to do it 
and, more important, there seems to be no recourse to fix it. The SPDs for 
MBASIC and CP/M say they are sold "as is” with no means for getting them fixed 
or even asking what to do about the problem so there you are, stuck with 
hardware and software that will not work and nothing you can do about it. The 
SPDs don't actually say the software will work in this case but they certainly 
do not say it will not and it is a reasonable assumption for anyone familiar 
with small systems like this that the software will work with the built in 
hardware facilities unless stated otherwise. 


But - good news - since the last Newsletter went to press, I have had a 
chance to try a version of OS/8 that runs on the DECmate II. This is more or 
less the same as the one demonstrated at the DECUS Spring Symposium. It has not 
been announced as a product but it has been under development since the 
beginning of the DECmate II development project. 


All I had to work with was a floppy disk, no manuals or other information 
to go with it. So, I got out my OS/78 version 4 manual and reread it cover to 
cover. It was great reading it after fighting through the DECmate II CP/M 
documentation. 0S/8 is soooo nice compared to that! I booted up 0S/8, found it 
prompted with the curly bracket instead of the familiar dot - a great departure 
from a long and proud tradition but one I can live with if I have too, 
particularly because I found that another long tradition, the need to type your 
commands in upper case, was largely removed. I presume this would be 
implemented fully by the time such a product was released, if ever. 


Even without documentation, as an experienced user I had no problem at all 
finding my way around the new version. It was great being back with an old 
friend on this great new machine. The DECmate II is fast, it looks great, the 
price is right and it is a lot of fun with 0S/8. Lots of new opportunities and 
challenges. 


I also had a chance to see a technical run down on the insides of the 
machine. It turns out that the communications port is rather tricky to program 
but the printer port is really a full, bidirectional serial port just like the 
ones on earlier systems. Except for the funny thing all the DECmates do when 
they do skip on flag, it is just like every KL8 style port in the world. I 
decided to see if I could write a device driver for the port since there were 
none on the disk I had. First, in about five minutes I had a simple PAL8 
program going that demonstrated the port worked as advertised and it could 
accept input from the tablet with no problem. Next, to save some time, I pulled 
in a copy of the source for the old KL8E handler from OS/8 V3D and edited a 
couple of lines to set it up for the location of the printer port as SLU2:. I 
assembled it, built the handler image and installed it in the system. It worked 
the first time! 


The version of BASIC on this disk has been updated a good bit. I think it 
may be a version that will only run on DECmates now - maybe only DECmate IIs I 
do not know. In any case it worked fine, everything I know about 0S/78 BASIC 
still worked, and I noticed that some very nifty new features had been added. I 
certainly hope it becomes available! 


Anyway, within the hour I had taught the researcher who was using the 
tablet how to use 0S/8, written a basic data acquisition program and had him 
using it. Some difference from the CP/M experience I must say! At this point 
it would seem to be out of the question for even an experienced CP/M user to 
adapt it the way I was able to do with OS/8 because of the way it is implemented 
on the DECmate and because of the lack of information required to do it. 


If DEC's promised spelling checker for WPS on the DECmate II requires the 
purchase of a Winchester disk as we have been told by DEC, I would be tempted to 
write one that runs under 0S/8 using only the floppy disks. The tools are 
there, all we need is for OS/8 to be available. The latest rumor I heard is 
that DEC might put this version of 0S/8 in DECUS. The story before that, in the 
Spring, was that it was going to be released as a product. I really don't care 
much as long as the price is reasonable and it is AVAILABLE! I also hope DEC 
WILL put FORTRAN IV back in or else make it possible for the user community to 
do something to get it going for the new system and make it available. 


64 


NOTE FROM DR JOSEPH R GIGANTI 


Here is a note that I think was lost in the scramble to get out the "last 
free" issue of the Newsletter last Spring. It still seems to be worth 
publishing. Sorry for the delay. 


"It certainly was nice to see a copy of the newsletter (#41) again. I 
depend on it and consider it a vital line of user communication. I would be 
more than happy to pay for it if that's what it will take to keep it coming. 


"I would like to start a 12 bit user group in the Minneapolis and St. Paul 
area. An announcement in the Newsletter may help to spread the word. 


"On the subject of the newsletter, here are a few ideas which you may wish 
to expose in the next edition: 


1) Let's get a bit of capitalism into the PDP8 user community. I would 
like to see advertisements for user generated software available from 
the authors directly. This has been the major driving force behind the 
development of personal computers and it can work for us as well. 


2) If advertizing in any form is disallowed, I suggest we all agree on an 
inexpensive national publication to which we could subscribe and use it 
for announcements, advertising, etc. For this purpose, my suggestion is 
the COMPUTER SHOPPER (407 S. Washington Ave, Titusville, FL 32780). 
Subscriptions are only $10/year, their advertising rates are rock bottom 
and they have a DEC classification. 


3) The falling prices for pre-owned equipment has made it easier to own, 
but harder to locate. It simply isn't worth the effort to advertise. I 
feel the newsletter, in an appropriate section, could list users with 
surplus equipment in a brief manner including phone number. Again, this 
involves extra work which I'me sure you don't need. The newsletter 
preparation could be distributed among several individuals. 
Alternatively, repeated notices in each newsletter entreating the 
community to advertise their available equipment in a designated 
publication such as the one above may help. Only in these efforts can 
we hope to recycle this well made equipment back to those who are 
interested in maintaining their systems. 


"A local used equipment vendor (Midwest Systems) told me the other day they 
are currently shipping 25 8a's a month!! Clearly there is a basis for the 12 
bit community, but I'me less sure DEC should be behind the effort." 


Dr. Giganti makes some very good points. The reason many of his ideas have 
not happened before now is the conservative policies of DECUS. We operate under 
very strong "non-commercialism" rules that severly limit our ability to do many 
things that need to be done. The reasons for this are a desire to maintain 
DECUS as a certain type of organization and to try to balance user needs against 
what our leadership thinks are DEC's needs. They feel that if we go too far we 
risk alienating our special relationship with DEC that has made DECUS so 
effective over the years. I have argued very much along Dr. Giganti's lines for 
many years with little success. It may be that our needs are unique in the DEC 
world or maybe just that we are the pioneers and that as other systems grow old 
more of DECUS will see what we see. 
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I do think the move away from DECUS publications toward commercial 
magazines is becoming a clear trend that represents a very important problem for 
DECUS. So far I have not seen the will in DECUS to address the issue in a way 
that will be successful. 


Dr. Giganti is at Radimetrix, inc, 1785 Taconite Point, St. Paul, MN 55122, 
(612)-452-4982. I hope those of you in his area will take him up on his offer 
to organize a local user group. DECUS is becoming very interested in 
encouraging this type activity. Anyone interested in organizing a local user 
group in their area can contact me and I will get you in touch with the people 
in DECUS who can help you. (RH) 


NOTE FROM IAN TEMPLETON 


"I was delighted to here from Wally Kalinowski that the 12-Bit SIG 
Newsletter is still alive and well, even though in new clothing. I was also 
glad to hear that DSN is still available. Unfortunately the order number quoted 
in Newsletter #41 apparently doesn't apply in Canada, so I may be in for a 
struggle to find out how to get it. I haven't had an issue since Oct/Nov 81. 
(Ed. note: Since the more recent note in the Newsletter reporting similar 
problems with DSN in the US, I have not heard from anyone who has been able to 
get it. - RH) 


"T have two new pieces of information. 


1. My "Scope-Type Rubouts in FRTS (#40 p25) has a problem when the .LD 
module overwrites the flag word 17726. To deal with this, FRTS should 
call the rubout routine before the .LD module is loaded. This can be 
done somewhere in the string of NOP's between 04020 and 04032 in FRTS by 
inserting JMS I .+2, SKP, 7550. The ‘once only’ section of the routine 
is then done and all will be well thereafter. 


2. As Wally may have told you, a rather bright summer student of ours (Andy 
Summers) managed to unravel the intricacies and contradictions of the 
IEEE 488 Bus specifications and designed an interface for the PDP8/E 
using the DEC M1709 Omnibus Interface Board. This allows the 8/E to be 
the (only) controller of the system. We have four different 
instruments, All Hewlett-Packard. These are scanner, DVM, counter and 
plotter and all can be controlled and read happily with Fortran IV, 
using a RALF subroutine package I have written. I recently had a 
request from a colleague, who has a copy of the interface and wanted to 
use FOCAL to drive a plotter, to write a handler as well. This I have 
done, though it had to be split into two: a 1-page handler for Bus 
initialising and SRQ testing; and a 2-page handler to send commands and 
messages, and to read data and status. He reports that the combination 
works well. The handlers have the advantage that one can test command 
and message strings by sending them to the Bus from TTY using PIP. 
Anyway, for anyone interested I have full circuit diagrams available and 
can also provide the driver modules, preferably on a floppy disk. My 
address is: 


Dr. I.M. Templeton 
Room 150, M-23A 
National Research Council of Canada 
Ottawa, Canada K1AOR6 
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(613) 993-9880 


"Best wishes for the New Year." 
NOTE FROM RON LARKIN ON BOB PHELPS’ USR 


Ron Larkin called recently looking for help with a problem he was having 
with Bob Phelps’ USR (DECUS 8-850: "USR and other Special Purpose Subroutines 
for OS/8 FORTRAN IV" - a package that has proven very valuable to many, many 
OS/8 FORTRAN IV users). When he used USR with a new disk and controller that 
worked fine the rest of the time he had trouble. Ron later sent along the 
following note about what he found. It points out a very subtle point about 
OS/8 and the way PDP8 DMA devices need to be handled. 


"Thank you for your advice on the problem with Phelps' USR. It turns out 
that the phone number you have for him reaches the Graduate School of Management 


or something at Rochester -- he appears to have disappeared into the private 
sector. 


"My problem was hardware: the CESI MDC8 controller can transfer up to 32k 
words at a call, right across Field boundaries. Phelps’ routine takes advantage 
of the cute "feature" of an OS/8 handler that permits I/0 transfers to 
wraparound within a Field; USR reads from SYS: into the top part of the 
correct Field and then the hardware continued blithely into the next (incorrect) 
Field. The OS/8 Software Support Manual, page 4-3, documents the "feature" of 
0S/8. 


"I found it interesting that the rest of OS/8, FORTRAN IV, FRTS, and all 
user and utility programs I have tried operated nominally, probably because the 
"feature" of OS/8 is seldom used." 


Ron is at Illinois State Natural History Survey, Wildlife Research, Natural 
Resources Building, 607 East Peabody Drive, Champaign, IL 61820, (217)333-6880. 


Kd. note: I recall some phone discussions with Bob Phelps about the 
design of USR. It gives the ability to open and close files on the fly from 
within FORTRAN programs, a capability I understand was left out by DEC due to a 
shortage of time and resources. It is no small task to do given the constraints 
on space and so on in FRTS. What I recall as particularly interesting was that 
Bob did not have access to sources of FRITS, the FORTRAN runtime system, so he 
could not just add some code to it. In fact, as I recall, he had to manually 
disassemble parts of FRTS and try to trace the code to figure out what to. 
Given all this and the intricacies and poor documentation of RALF coding, it is 
little wonder that there are some rather unique coding techniques in USR. In 
fact, I remember finding it very interesting to read the code and figure out 
just how it really did work. (RH) 
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